1. Field of the Invention
The present invention relates generally to transaction processing and, in particular, to last-agent optimization in two-phase commits.
2. Description of Related Art
Any operation involving multiple entities that requires a homogeneous outcome requires some sort of external coordination to ensure that each entity receives the same outcome. A distributed transaction is one example of such an operation. A transaction generally has two possible outcomes: commit or rollback. To ensure that the outcome is homogeneous, a protocol known as two-phase commit is used. An entity that manages transactional resources is known as a resource manager.
In the two-phase commit process, each resource enlisted in the transaction is first asked to prepare to commit and, then, is directed to commit. During the first phase, resource managers confirm that it can successfully complete the commit by replying with an okay value. If all the resources are okay to commit, a log record is written to indicate the outcome and all the resources are committed. If any resource cannot confirm that the commit will succeed, all the resources are rolled back. If the outcome is rollback, no log record is generally written, because the default outcome is rollback (presumed abort). When all the resources execute the same outcome successfully, the outcome is said to be atomic.
A transaction manager is typically responsible for grouping and ordering the resources to be driven. Assuming that each call to prepare, commit, and rollback have to be driven to a subordinate resource over a network, a two-phase transaction results in one log write and 2n number of calls over the network, where n is the number of resources enlisted in the transaction.
If only one resource is enlisted in a transaction, the prepare phase and log write become unnecessary, as there is only one resource and, therefore, the outcome of the transaction will be atomic regardless of whether the prepare call is successful. In this case, the single resource is simply asked to commit, and the overall outcome is commit. If the commit fails, the overall outcome becomes rollback. This optimization is called one-phase commit or only-agent.
There is a need to further optimize the two-phase commit process that collapses select transactions that normally require a two-phase commit to a one-phase commit, (a/k/a last-agent optimization). When asked to prepare, a resource could return a read-only value if the resource has no updates to complete on the subsequent commit or rollback call. If there are n resources enlisted in the transactions, and the first n−1 resources vote read-only on the prepare call, then the remaining resource would become the only resource enlisted and a one-phase commit could be performed on it. This needed optimization is known as a last-agent optimization, because the last resource (or agent) would be able to perform the one-phase commit optimization and still maintain a homogenous outcome for the overall transaction. In this case, the total number of network calls required to commit the transaction would be reduced to n and there would be no need to log after the prepare phase.